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ABSTRACT 


The increasingly familiar and ubiquitous Re- 
ference Model of Open Systems Interconnection, 
currently being considered by the International 
Organization for Standardization (ISO) for 
promotion to the status of a Draft International 
Standard, is based on the explicit assumption 


that a "connection" - an association between two 
or more communicating entities, possessing 
certain characteristics over and above those 
possessed by the entities themselves - is 
required for the transfer of data in an Open 
Systems Interconnection (OST) environment. 
Although the connection-oriented model of 


communications behavior has proven to be an 
extremely powerful concept, and has been applied 
successfully to the design and implementation of 
protocols and systems covering a wide range of 
applications, a growing body of research and 
experience suggests that a complementary concept 
— connectionless data transmission - is an 
essential part of the Open Systems Interconnec-— 
tion architecture, and should be embraced as 
such by the OSI Reference Model. This paper 
explores the concept of connectionless data 
transmission and its relationship to the more 
familiar concepts of connection-oriented data 
transfer, developing a rationale for the inclu- 
sion of the connectionless concept in the 
Reference Model as an integral part of the 
standard description of the OSI architecture. 
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il 


Introduction 


Over the past three years, a number of national and interna- 
tional standards organizations have expended the time and 
efforts of a great many people to achieve a description of an 
architectural Reference Model for interconnecting computer 
systems considered to be "open" by virtue of their mutual use of 
standard communication protocols and formats. The current 
description, the Reference Model of Open Systems Interconnection 
(RM/OSI) [1], is generally accepted by the International Organi- 
zation for Standardization (ISO), the International Telephone 
and Telegraph Consultatitive Committee (CCITT), the European 
Computer Manufacturer's Association (ECMA), and many national 
standards bodies, including the American National Standards 
Institute (ANSI), and has progressed to the status of a Draft 
Proposed Standard (DP7498) within ISO. It describes the con- 
cepts and principles of a communications architecture organized 
hierarchically, by function, into seven discrete layers, and 
prescribes the services that each layer must provide to the 
layer immediately above it (the uppermost layer provides its 
services to user applications, which are considered to be 
outside of the Open Systems Interconnection environment). 
Building on the services available to it from the next-lower 
layer, each layer makes use of standard OSI protocols which 
enable it to cooperate with other instances of the same layer 
(its "peers") in other systems (see Figure 1). This technique 
of grouping related functions into distinct layers, each of 
which implements a set of well-defined services that are used by 
the layer above, partitions a very complex, abstract problem - 
"how can the components of a distributed application, operating 
in potentially dissimilar environments, cooperate with each 
other?" — into a number of more manageable problems that enjoy a 
logical relationship to each other and can individually be more 
readily understood. 


The Reference Model was developed to serve as a framework for 
the coordination of existing and future standards designed to 
facilitate the interconnection of data processing systems. The 
purpose of OSI is to enable an end-user application activity 
(called an "application process") located in a system that 
employs OSI procedures and protocols (an "open" system) to 
communicate with any other appication process located in any 
other open system. It is not the intent of OSI to specify 
either the functions or the implementation details of systems 
that provide the OSI capabilities. Communication is achieved by 
mutual adherence to agreed-upon (standardized) services and 
protocols; the only thing that an OSI entity in a given layer in 
one system needs to know about an OSI entity in the same layer 


User of (N)-services User of (N)-services 


[an (N+1)-entity] [an (N+1)-entity] 
\ / 
\ / 
\ /----- (N) -service-access-points----- \ / (N+1) 
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\ / (N) 
\<----- services provided to------ >/ 
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\ / 
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FIGURE 1 - General Model of an OSI Layer 


A Note on OSI Terminology 


The construction of a formal system, such as the architecture of 
Open Systems Interconnection, necessarily involves the introduc- 
tion of unambiguous terminology (which also tends to be somewhat 
impenetrable at first glance). The terms found here and in the 
text are all defined in an Appendix. The "(N)-" notation is used 
to emphasize that the term refers to an OSI characteristic that 
applies to each layer individually. The "(N)-" prefix stands in 
generically for the name of a layer; thus, "(N)-address", for 
example, refers abstractly to the concept of an address associa- 
ted with a specific layer, while "transport-address" refers to 
the same concept applied to the transport layer. 
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of another system is how the other entity behaves, not how it is 
implemented. In particular, OSI is not concerned with how the 
interfaces between adjacent layers are implemented in an open 
system; any interface mechanism is acceptable, as long as it 
supports access to the appropriate standard OSI services. 


A major goal of the OSI standardization effort is generality. 
Ideally, the Reference Model should serve as the common archi- 
tectural framework for many different types of distributed 
systems employing a wide range of telecommunication 
technologies, and certainly an important measure of the success 
of OSI will be its ability to apply the standard architecture 
across a broad spectrum of user applications. The way in which 
the Reference Model has developed over the past four years 
reflects an awareness of this goal (among others): the process 
began with the identification of the essential concepts of a 
layered architecture, including the general architectural 
elements of protocols, and proceeded carefully from these basic 
principles to a detailed description of each layer. The organi- 
zation of the current Reference Model document [1] exhibits the 
same top-down progression. At the highest level, three elements 
are identified as basic to the architecture[1]: 


a) the application processes which exist within the Open 
Systems Interconnection environment; 


b) the connections which join the application processes and 
permit them to exchange information; and 


c) systems. 


The assumption that a connection is a fundamental prerequisite 
for communication in the OSI environment permeates the Reference 
Model, and is in fact one of the most useful and important 
unifying concepts of the architecture. A growing number of 
experts in the field, however, believe that this deeply-rooted 
connection orientation seriously and unnecessarily limits the 
power and scope of the Reference Model, since it excludes a 
large class of applications and implementation technologies that 
have an inherently connectionless nature. They argue that the 
architectural objectives of the Reference Model do not depend on 
the exclusive use of connections to characterize all OSI 
interactions, and recommend that the two alternatives - connec- 
tion oriented data transfer, and connectionless data transmis- 
sion - be treated as complementary concepts, which can be 
applied in parallel to the different applications for which each 
is suited. 


At the November, 1980 meeting of the ISO subcommittee responsi- 
ble for OSI (TC97/SC16), a working party laid a solid foundation 
for this argument in two documents: Report of the Ad Hoc Group 
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on Connectionless Data Transmission[3], and Recommended Changes 
to Section 3 of [the Reference Model] to Include Connectionless 
Data Transmission[2]; and the importance of the issue was 
recognized by the full subcommittee in a resolution[25] calling 
for comments on the two documents from all member organizations. 
The question of how the connectionless data transmission concept 
should be reflected in the OSI architecture - and in particular, 
whether or not it should become an integral part of the Re- 
ference Model - will be debated again this summer, when the 
current Draft Proposed Standard Reference Model becomes a Draft 
International Standard. The remainder of this article will 
explore the issues that surround this question. 


2 What Is Connectionless Data Transmission? 


Connectionless data transmission (CDT), despite the unfamiliar 


name, is by no means a new concept. In one form or another, it 
has played an important role in the specification of services 
and protocols for over a decade. The terms "message mode"[ ], 
"datagram"[35], "transaction mode" [22,23,241], and 


"connection-free"[37,47] have been used in the literature to 
describe variations on the same basic theme: the transmission of 
a data unit in a single self-contained operation without 
establishing, maintaining, and terminating a connection. 


Since connectionless data transmission and connection-oriented 
data transfer are complementary concepts, they are best under- 
stood in juxtaposition, particularly since CDT is most often 
defined by its relationship to the more familiar concept of a 
connection. 


2.1 Connection-Oriented Data Transfer 


A connection (or "(N)-connection", in the formal terminology of 
OSI) is an association established between two or more entities 
("(N+1)-entities") for conveying data 
("(N) -service-data-units"). The ability to establish 
(N) -connections, and to convey data units over them, is provided 
to (N+1)-entities by the (N)-layer as a set of services, called 


connection-oriented (N)-services. Connection-oriented interac- 
tions proceed through three distinct sequential phases: connec- 
tion establishment; data transfer; and connection release. 
Figure 2 illustrates schematically the sequence of operations 
associated with connection-oriented interactions. In addition 
to this explicitly distinguishable duration, or "lifetime", a 


connection exhibits the following fundamental characteristics: 


Connection Establishment 


— Successful - — Unsuccessful - 
~- | | ~N- | | 
connect | | (N) -connect connect | | (N)- 
------- >| |indication ------->| | connect 
request | | request | | indication 
|V |------- > ee ==- > 
(N) -LAYER (N) -LAYER 
(N) - Soe (N) - Saye ee 
connect | | disconnect | | (N)- 
K-=-==== | | (N) -connect <-==-=== | disconnect 
confirm | | response indication | | request 
| | | 
Data Transfer 
~- | | (N)- | | 
data (N) -data data 
Hessen > indication ===> (N) - 
request | | request | | data 
| |------- > | |indication 
| (N) -LAYER | | (N) -LAYER |------- > 
| | (y=. | | 
data 
| | | | 
| | confirm | | 
| | | 
Connection Release 
— User Initiated - — Provider Initiated - 
(N)-dis | | | | 
connect | | (N)- | |  (N)- 
Houden >| (N)-LAYER | (N) -disconnect disconnect | (N) -LAYER |disconnect 
request | | indication RSSssess].  (|======= > 
| |------- > indication | |indication 
| | 
FIGURE 2 - Connection Oriented Interaction 
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[Note: Much of the material in this section is 
derived from reference 3] 


1. Prior negotiation. 


In a connection-oriented interaction, no connection is esta- 
blished - and no data are transferred - until all parties agree 
on the set of parameters and options that will govern the data 
transfer. An incoming connection establishment request can be 
rejected if it asserts parameter values or options that are 
unacceptable to the receiver, and the receiver may in many cases 
suggest alternative parameter values and options along with his 
rejection. 


The reason for negotiation during connection establishment is 
the assumption that each party must reserve or allocate the 
resources (such as buffers and channels) that will be required 
to carry out data transfer operations on the new connection. 
Negotiation provides an opportunity to scuttle the establishment 
of a connection when the resources that would be required to 
support it cannot be dedicated, or to propose alternatives that 
could be supported by the available resources. 


2. Three-party Agreement. 


The fundamental nature of a connection involves establishing and 
dynamically maintaining a three-party agreement concerning the 
transfer of data. The three parties - the two (Nt1)-entities 
that wish to communicate, and the (N)-service that provides them 
with a connection - must first agree on their mutual willingness 
to participate in the transfer (see above). This initial 
agreement establishes a connection. Thereafter, for as long as 
the connection persists, they must continue to agree on the 
acceptance of each data unit transferred over the connection. 
"With a connection, there is no possibility of data transfer 
through an unwilling service to an unwilling partner, because 
the mutual willingness must be established before the data 
transfer can take place, and data must be accepted by the 


destination partner; otherwise, no data [are] transferred on 
that connection."[3] 

3. Connection Identifiers. 

At connection establishment time, each participating 


(N+1)-entity is identified to the (N)-service by an (N)-address; 
the (N)-service uses these addresses to set up the requested 
connection. Subsequent requests to transfer data over the 
connection (or to release it) refer not to the  (N)-address (es) 
of the intended recipient(s), but to a connection identifier 
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supplied by the (N) -service (in OSI parlance, an 
"(N)-connection-endpoint-identifier"). This is a 
locally-significant "shorthand" reference that uniquely identi- 
fies an established connection during its lifetime. Similarly, 
the protocol units that carry data between systems typically 
include a mutually-understood logical identifier rather than the 
actual addresses of the correspondents. This technique elimina- 
tes the overhead that would otherwise be associated with the 
resolution and transmission of addresses on every data transfer. 
In some cases, however - particularly when non-homogeneous 
networks are interconnected, and very location-sensitive addres- 
sing schemes are used - it can make dynamic routing of data 
units extremely difficult, if not impossible. 


4. Data Unit Relationship. 


Once a connection has been established, it may be used to 
transfer one data unit after another, until the connection is 
released by one of the three parties. These data units are 
logically related to each other simply by virtue of being 
transferred on the same connection. Since data units are 
transferred over a connection in sequence, they are related 
ordinally as well. These data unit relationships are an impor- 
tant characteristic of connections, since they create a context 
for the interpretation of arriving data units that is indepen- 
dent of the data themselves. Because a connection maintains the 
sequence of messages associated with it, out-of-sequence, 
missing, and duplicated messages can easily be detected and 
recovered, and flow control techniques can be invoked to ensure 
that the message transfer rate does not exceed that which the 
correspondents are capable of handling. 


These characteristics make connection-based data transfer 
attractive in applications that call for relatively long-lived, 
stream-oriented interactions in stable configurations, such as 
direct terminal use of a remote computer, file transfer, and 


long-term attachments of remote job entry stations. In such 
applications, the interaction between communicating entities is 
modelled very well by the connection concept: the entities 


initially discuss their requirements and agree to the terms of 
their interaction, reserving whatever resources they will need; 
transfer a series of related data units to accomplish their 
mutual objective; and explicitly end their interaction, releas- 
ing the previously reserved resources. 


2.2 Connectionless Data Transmission 


In many other applications, however, the interaction between 
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entities is more naturally modelled by the connectionless data 
transmission concept, which involves the transmission of a 
single self-contained data unit from one entity to another 
without prior negotiation or agreement, and without the as- 
surance of delivery normally associated with connection-based 
transfers. The users of a connectionless (N)-service may, of 
course, use their (N+1)-protocol to make any prior or dynamic 
arrangements they wish concerning their interpretation of the 
data transmitted and received; the (N)-service itself, however, 
attaches no significance to individual data units, and does not 
attempt to relate them in any way. Two (N+1)-entities communi- 
cating by means of a connectionless (N)-service could, for 
example, apply whatever techniques they might consider appro- 
priate in the execution of their own protocol (timers, 
retransmission, positive or negative acknowledgements, sequence 
numbers, etc.) to achieve the level of error detection and/or 
recovery they desired. Users of a connectionless, as opposed to 
connection-oriented, (N)-service are not restricted or inhibited 
in the performance of their (N+1)-protocol; obviously, though, 
the assumption is that CDT will be used in situations that 
either do not require the characteristics of a connection, or 
actively benefit from the alternative characteristics of connec- 
tionless transmission. 


Figure 3 illustrates schematically the single operation whereby 
a connectionless service may be employed to transmit a single 
data unit. Figure 4 shows a widely-implemented variation, 
sometimes called "reliable datagram" service, in which the 
service provider undertakes to confirm the delivery or 
non-delivery of each data unit. It must be emphasized that this 
is not a true connectionless service, but is in some sense a 
hybrid, combining the delivery assurance of connection-oriented 
service with the single-operation interface event of connection- 
less service. 


Many of those involved in OSI standardization activities have 


agreed on a pair of definitions for connectionless data 
transmission, one for architectural and conceptual purposes, and 
one for service-definition purposes[4]. The architectural 


definition, which has been proposed for inclusion in the Re- 
ference Model, is: 


"Connectionless Data Transmission is the transmission (not 
transfer) of an (N) -service-data-unit from a source 
(N) -service-access-point to one or more destination 


(N) -service-access-points without establishing an (N)-connection 
for the transmission." 


The service definition, which is intended to provide a workable 
basis for incorporating a connectionless service into the 


(N) -data 


request | 
maas >| 
| (N) -LAYER 
| e or a 
(N) -data 
| indication 
| | 
FIGURE 3 — Connectionless Data Transmission 
(N) -data 
request 
Peete sere >| | 
| | (N)-data 
| (N) -LAYER pa: i 
| | indication 
deo eee 
(N) -data 
confirm | | 


FIGURE 4 — "Reliable Datagram" Service 
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service descriptions for individual layers of the Reference 
Model, is: 


"A Connectionless (N)-Service is one that accomplishes the 
transmission of a single self-contained (N)-service-data-unit 
between (N+1)-entities upon the performance of a single 
(N)-service access." 


Both of these definitions depend heavily on the distinction 
between the terms "transmit", "transfer", and "exchange": 


Transmit: "to cause to pass or be conveyed through space or a 
medium." This term refers to the act of conveying only, without 
implying anything about reception. 


Transfer: "to convey from one place, person, or thing, to 
another." A one-way peer-to-peer connotation restricts the use 
of this term to cases in which the receiving peer is party to 
and accepts the data transferred. 


Exchange: "to give and receive, or lose and take, reciprocally, 
as things of the same kind." A two-way peer-to-peer connotation 
restricts the use of this term to cases in which both give and 
receive directions are clearly evident. 


These definitions are clearly of limited usefulness by 
themselves. They do, however, provide a framework within which 
to explore the following characteristics of CDT: 


1. "One-shot" Operation. 


The most user-visible characteristic of connectionless data 
transmission is the single service access required to initiate 
the transmission of a data unit. All of the information re- 
quired to deliver the data unit - destination address, quality 
of service selection, options, etc. - is presented to the 
connectionless (N)-service provider, along with the data, in a 
single logical service-access operation that is not considered 
by the (N)-service to be related in any way to other access 
operations, prior or subsequent (note, however, that since OSI 
is not concerned with implementation details, the specific 
interface mechanism employed by a particular implementation of 
connectionless service might involve more than one interface 
exchange to accomplish what is, from a logical standpoint, a 
Single operation). Once the service provider has accepted a 
data unit for connectionless transmission, no further communica- 
tion occurs between the provider and the user of the service 
concerning the fate or disposition of the data. 
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2. Two-party Agreement. 


Connection-oriented data transfer requires the establishment of 
a three-party agreement between the participating (N+1)-entities 
and the (N)-service. A connectionless service, however, invol- 
ves only two-party agreements: there may be an agreement between 
the corresponding (N+1)-entities, unknown to the (N)-service, 
and there may be local agreements between each (N+1)-entity and 
its local (N)-service provider, but no (N)-protocol information 
is ever exchanged between (N)-entities concerning the mutual 
willingness of the (N+1)-entities to engage in a connectionless 
transmission or to accept a particular data unit. 


In practice, some sort of a priori agreement (usually a system 
engineering design decision) is assumed to exist between the 
(N+1)-entities and the (N)-service concerning those parameters, 
formats, and options that affect all three parties as a unit. 
However, considerable freedom of choice is preserved by allowing 
the user of a connectionless service to specify most parameter 
values and options - such as transfer rate, acceptable error 
rate, etc. - at the time the service is invoked. In a given 
implementation, if the local (N)-service provider determines 
immediately (from information available to it locally) that the 
requested operation cannot be performed under the conditions 
specified, it may abort the service primitive, returning an 
implementation-specific error message across the interface to 
the user. If the same determination is made later on, after the 
service-primitive interface event has completed, the transmis- 
sion is simply abandoned, since users of a connectionless 
service can be expected to recover lost data if it is important 
for them to do so. 


3. Self-contained Data Units. 


Data units transmitted via a connectionless service, since they 
bear no relationship either to other data units or to a "higher 
abstraction" (such as a connection), are entirely 
self-contained. All of the addressing and other information 
needed by the service provider to deliver a data unit to its 
destination must be included in each transmission. On the one 
hand, this represents a greater overhead than is incurred during 
the data transfer phase of a connection-oriented interaction; on 
the other, it greatly simplifies routing, since each data unit 
carries a complete destination address and can be routed without 
reference to connection-related information that may not, for 
example, be readily available at intermediate nodes. 


4. Data Unit Independence. 


The connectionless transmission of data creates no relationship, 
express or implied, between data units. Each invocation of a 
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connectionless service begins the transmission of a single data 
unit. Nothing about the service invocation, the transmission of 
the data by the connectionless service, or the data unit itself 
affects or is affected by any other past, present, or future 
operation, whether connection-oriented or connectionless. A 
series of data units handed one after the other to a connection- 
less service for delivery to the same destination will not 
necessarily be delivered to the destination in the same order; 
and the connectionless service will make no attempt to report or 
recover instances of non-delivery. 


Note: A number of popular variations on CDT include 
features that run counter to those described 
above. These variations deserve to be discussed 


on their own merits, but should not be confused 
with the architectural concept of connectionless 
data transmission. 


These characteristics make CDT attractive in applications that 
involve short-term request-response interactions, exhibit a high 
level of redundancy, must be flexibly reconfigurable, or derive 
no benefit from guaranteed in-sequence delivery of data. 


3 The Rationale for Connectionless Data Transmission 


Because CDT is not as widely understood as connection-oriented 
data transfer, it has often been difficult in the course of 
developing service and protocol definitions to adduce a ration- 
ale for incorporating CDT, and even more difficult to determine 
appropriate locations for connectionless service within the 
layered hierarchy of OSI. This section addresses the first 
concern; the next section will deal with the second. 


The most natural way to discover the power and utility of the 
CDT concept is to examine applications and implementation 
technologies that depend on it. The following observations are 
distilled from the specifications and descriptions of actual 
protocols and systems (many of which have been implemented), and 
from the work of individuals and organizations engaged in the 
OSI standardization effort (quoted material is from reference 3, 
except where otherwise noted). They are divided into seven 
(occassionally overlapping) categories which classify the 
applications for which CDT is well suited. 


Inward data collection involves the periodic active or passive 
sampling of a large number of data sources. A sensor net 


Connectionless Data Transmission, Rev. 1.00 


gathering data from dedicated measurement stations; a network 
status monitor constantly refreshing its knowledge of a network 
environment; and an automatic alarm or security system in which 
each component regularly self-tests and reports the result, are 


all engaged in this type of interaction, in which a "large 
number of sources may be reporting periodically and asynchron- 
ously to a single reporting point. In a realtime monitoring 


situation, these readings could normally be lost on occassion 
without causing distress, because the next update would be 
arriving shortly. Only if more than one successive update 
failed to arrive within a specified time limit would an alarm be 
warranted. If, say, a fast connect /disconnect three-way 
handshake cost twice as much as a one-way [connectionless] data 
transmission which had been system engineered to achieve a 
certain acceptable statistical reliability figure, the cost of 
connection-oriented inward data collection for a large distri- 
buted application could be substantially greater than for 
[connectionless collection], without a correspondingly greater 
benefit to the user."[3] 


Outward data dissemination is in a sense the inverse of the 
first category; it concerns the distribution of a single data 
unit to a large number of destinations. This situation is 
found, for example, when a node joins a network, or a 
commonly-accessible server changes its location, and a new 
address is sent to other nodes on the network; when a synchroni- 
zing message such as a real-time clock value must be sent to all 
participants in some distributed activity; and when an operator 
broadcasts a nonspecific message (e.g., "Network coming down in 
five minutes"). In such cases, the distribution cost (including 
time) may far exceed the cost of generating the data; control- 
ling the overall cost depends on keeping the cost of dissemina- 
tion as low as possible. 


Request-response applications are those in which a service is 
provided by a commonly accessible server process to a large 
number of distributed request sources. The typical interaction 
consists of a single request followed by a single response, and 
usually only the highest-level acknowledgement - the response 
itself - is either necessary or meaningful. Many commercial 
applications (point of sale terminals, credit checking, reserva- 
tion systems, inventory control, and automated banking systems) 
and some types of industrial process control, as well as more 
general information retrieval systems (such as videotex), fall 
into this category. In each case, the knowledge and expectation 
of each application component as to the nature of the interac- 
tion is represented in an application-process design and imple- 
mentation that is known in advance, outside of OSI; lower level 
negotiations, acknowledgements, and other connection-related 
functions are often unnecessary and cumbersome. 
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An example of an application that combines the characteristics 
of inward data collection, outward data dissemination, and 
request-response interaction is described by the Working Group 
on Power System Control Centers of the IEEE Power Engineering 
Society in a recent letter to the chairman of ANSI committee 
X3T51 concerning the use of data communication in utility 


control centers[17]. They note that "a utility control center 
receives information from remote terminal units (located at 
substations and generating plants) and from other control 


centers, performs a variety of monitoring and control functions, 
and transmits commands to the remote terminals and coordinating 
information to other control centers." During the course of 
these operations, the following conditions occur: 


1) Some measurements are transmitted or requested from 
remote terminals or control centers every few seconds. 
No attempt is necessarily made to recover data lost due 
to transmission error; the application programs include 
provisions for proper operation when input data is 
occassionally missing. [Inward data collection] 


2) Some data items are transferred from commonly accessed 
remote sites or multi-utility pool coordination centers 
on a request-response basis. [Request-response 
interaction] 


3) In some cases, an application program may require that 
some measurements be made simultaneously in a large 


number of locations. In these cases, the control center 
will broadcast a command to make th affected 
measurements. [Outward data dissemination] 


In closing, they note that "utility control centers around the 
world use data communications in ways similar to those in the 
United States." 


Broadcast and multicast (group addressed) communication using 
connection-oriented services is awkward at best and impossible 
at worst, notwithstanding the occassional mention of 
"multi-endpoint connections" in the Reference Model. Some 
characteristics of connection-based data transfer, such as 
sequencing and error recovery, are very difficult to provide in 
a broadcast/multicast environment, and may not even be 
desirable; and it is not at all easy to formulate a useful 
definition of broadcast/multicast acknowledgement that can be 
supported by a low-level protocol. Where group addressing is an 
important application consideration, connectionless data trans- 
mission is usually the only choice. 


Certain special applications, such as digitized voice, data 
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telemetry, and remote command and control, involving a high 
level of data redundancy and/or real-time transmission 
requirements, may profit from the fact that CDT makes no effort 
to detect or recover lost or corrupted data. If the time span 
during which an individual datum is meaningful is relatively 
short, since it is quickly superceded by the next - or if, as in 
digitized voice transmission, the loss or corruption of one or 
even several data units is insignificant - the application might 
suffer far more from the delay that would be introduced as a 
connection-oriented service dealt with a lost or out-of-sequence 
data unit (even if retransmission or other recovery procedures 
were not invoked) than it would from the unreported loss of a 
few data units in the course of a connectionless exchange. 
Other special considerations - such as the undesirability, for 
security reasons, of maintaining connection-state information 
between data transfers in a military command and control system 
— add force to the argument that CDT should be available as an 
alternative to connection-oriented data transfer. 


Local area networks (LANs) are probably the most fertile ground 
for connectionless services, which find useful application at 
several layers. LANs employ intrinsically reliable physical 
transmission media and techniques (baseband and broadband 
coaxial cable, fiber optics, etc.) in a restricted range 
(generally no greater than 1 or 2 kilometers), and are typically 
able to achieve extremely low bit error rates. In addition, the 
media-access contention mechanisms favored by LAN designers 
handle transmission errors as a matter of course. The usual 
approach to physical interconnection ties all nodes together on 
a common medium, creating an inherently broadcast environment in 
which every transmission can be received by every station. 
Taking advantage of these characteristics virtually demands a 
connectionless data link service, and in fact most current and 
proposed LANs - the Xerox Ethernet[43], the proposed IEEE 802 


LAN standard[14,46], and many others - depend on such a service. 
As a bonus, because connectionless services are simpler to 
implement - requiring only two or three service primitives - 


inexpensive VLSI implementations are often possible. 


In addition, the applications for which LANs are often installed 
tend to be precisely those best handled by CDT. Consider this 
list of eight application classes identified by the IEEE 802 
Interface Subcommittee as targets for the 802 LAN standard[46]: 


T Periodic status reporting - telemetry data from 
instrumentation, monitoring devices associated with static or 
dynamic physical environments; 


2. Special event reporting - fire alarms, overload or stressing 
conditions; 
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3. Security control - security door opening and closing, system 
recovery or initialization, access control; 


4. File transfer; 


5. Interactive transactions - reservation systems, electronic 
messaging and conferencing; 


6. Interactive information exchange - communicating text and 
word processors, electronic mail, remote job entry; 


7. Office information exchange - store and forward of digitized 
voice messages, digitized graphic/image handling; 


8. Real-time stimulus and response - universal product code 
checkout readers, distributed point of sale cash registers, 
military command and control, and other closed-loop and 
real-time applications. 


Of these, almost all have already been identified as classic 
examples of applications that have an essentially connectionless 


nature. Consider this more detailed example of (8): a local 
area network with a large number of nodes and a large number of 
services (e.g., file management, printing, plotting, job 
execution, etc.) provided at various nodes. In such a 


configuration, it is impractical to maintain a table at each 
node giving the address of every service, since changing the 
location of a single service would require updating the address 
table at every node. An alternative is to maintain a single 
independent "server lookup" service, which performs the function 
of mapping the name of a given service to the address of a 
server providing that service. The server-lookup server re- 
ceives requests such as, "where is service X?", and returns the 
address at which an instance of service X is currently located. 
Communication with the server-lookup server is inherently 
self-contained, consisting of a single request/response 
exchange. Only the highest-level acknowledgement - the response 
from the lookup service giving the requested address - is at all 
Significant. The native reliability of the local area network 
ensures a low error rate; if a message should be lost, no harm 
is done, since the request will simply be re-sent if a timely 
response does not arrive. Such an interaction is poorly model- 
led by the connection-oriented paradigm of opening a connection, 
transferring a stream of data, and closing the connection. It 
is perfectly suited to connectionless transmission techniques. 


Network interconnection (internetworking) can be facilitated - 
especially when networks of different types are involved, as is 
often the case - if the internetwork service is connectionless; 
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and a number of related activities, such as gateway-to-gateway 


communication, exhibit the request-response, inward data 
collection, and outward data dissemination characteristics that 
are well supported by CDT. One of the best examples of a 


connectionless internetwork service is described in a document 
published by the National Bureau of Standards (Features of 
Internetwork Protocol[29], which includes a straightforward 
discussion of the merits of the connectionless approach: 


"The greatest advantage of connectionless 
service at the internet level is simplicity, 
particularly in the gateways. Simplicity is 


manifested in terms of smaller and less compli- 
cated computer code and smaller computer storage 
requirements. The gateways and hosts are not 
required to maintain state information, nor 
interpret call request and call clear commands. 
Each data-unit can be treated 
independently...Connectionless service assumes a 
minim[al] service from the underlying 
subnetworks. This is advantageous if the 
networks are diverse. Existing internet proto- 
cols which are intended for interconnection of a 
diverse variety of networks are based on a 
connectionless service [for example the PUP 
Internetwork protocol[44], the Department of 
Defence Standard Internet Protocol[31], and the 
Delta-t protocol developed at Lawrence Livermore 
Laboratory[45]]." 


The principle motivating the development of internetwork servi- 
ces and protocols that make few assumptions about the nature of 
the individual network services (the "lowest common denominator" 
approach) was formulated by Carl Sunshine as the "local net 
independence principle"[39]: "Each local net shall retain its 
individual address space, routing algorithms, packet formats, 
protocols, traffic controls, fees, and other network character- 
istics to the greatest extent possible." The simplicity and 
robustness of connectionless internetworking systems guarantee 
their widespread use as the number of different network types - 
X.25 networks, LANs, packet radio networks, other broadcast 
networks, and satellite networks - increases and the pressures 
to interconnect them grow. 


4 CDT and the OSI Reference Model 


As a concept, connectionless data transmission complements the 
concept of connection-oriented data transfer throughout the OSI 
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architecture. As a basis for deriving standard OSI services and 
protocols, however, it has a greater impact on some layers of 
the Reference Model than on others. Careful analysis of the 
relative merits of connectionless and connection-oriented 
operation at each layer is necessary to control the prolifera- 
tion of incompatible or useless options and preserve a balance 
between the power of the complementary concepts and the stabili- 
zing objective of the OSI standardization effort. 


Figure 5 illustrates the layered OSI hierarchy as it is most 
commonly represented (it shows two instances of the hierarchy, 
representing the relationship between two OSI systems). The 
following sections discuss the CDT concept in the context of 
each of the seven layers. 


4.1 Physical Layer 


The duality of connections and connectionless service is diffi- 
cult to demonstrate satisfactorily at the physical layer, 
largely because the concept of a physical "connection" is both 
intuitive and colloquial. The physical layer is responsible for 
generating and interpreting signals represented for the purpose 
of transmission by some form of physical encoding (be it 
electrical, optical, acoustic, etc.), and a physical connection, 
in the most general sense (and restricting our consideration, as 
does the Reference Model itself, to telecommunications media), 
is a signal pathway through a medium or a combination of media. 
Is a packet radio broadcast network, then, using a 
"connectionless" physical service? No explicit signal pathway 
through a medium or media is established before data are 
transmitted. On the other hand, it can easily be argued that a 
physical connection is established with the introduction of two 
antennae into the "ether"; and if the antennae are aimed at each 
other and designed to handle microwave transmission, the impres- 
sion that a physical connection exists is strengthened. Whether 
or not one recognizes the possibility of connectionless physical 
services — other than purely whimsical ones - will probably 
continue to depend on one’s point of view, and will have no 
effect on the development of actual telecommunication systems. 


4.2 Data Link Layer 


Many data link technologies - particularly those coming into 
popular use with the growth of local area networking - are far 
easier to understand and work with when the traditional 
connection-oriented concepts (embodied, for example, in the 


widely-used HDLC, SDLC, and ADCCP standards) are replaced by the 
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concept of connectionless data transmission. The previous 
discussion of local area networking has already made the point 
that the high-speed, short-range, intrinsically reliable broad- 
cast transmission media used to interconnect stations in local 
area networks are complemented both functionally and concep- 
tually by connectionless data link techniques. 


One of the organizations currently developing a local area 
network data link layer standard - the Data Link and Media 
Access (DLMAC) subcommittee of IEEE 802 - has recognized both 
the need to retain compatibility with existing long-haul techni- 
ques and the unique advantages of CDT for local area networks by 
proposing that two data link procedures be defined for the IEEE 
802 standard. 


In one procedure, information frames are unnumbered and may be 
sent at any time by any station without first establishing a 
connection. The intended receiver may accept the frame and 
interpret it, but is under no obligation to do so, and may 
instead discard the frame with no notice to the sender. Neither 
is the sender notified if no station recognizes the address 
coded into the frame, and there is no receiver. This 
"connectionless" procedure, of course, assumes the "friendly" 
environment and higher-layer acceptance of responsibility that 
are usually characteristic of local area network 
implementations. 


The other procedure provides all of the sequencing, recovery, 
and other guarantees normally associated with 
connection-oriented link procedures. It is in fact very similar 
to the ISO standard HDLC balanced asynchronous mode procedure. 


Data link procedures designed for transmission media that 


(unlike those used in local area networks) suffer unacceptable 
error rates are almost universally connection-based, since it is 
generally more efficient to recover the point-to-point 


bit-stream errors detectable by connection-oriented data link 
procedures at the data link layer (with its comparatively short 
timeout intervals) than at a higher layer. 


4.3 Network Layer 


Connectionless network service is useful for many of the same 
reasons that were identified in the previous discussion of 
network interconnection: it greatly simplifies the design and 
implementation of systems; makes few assumptions about underly- 
ing services; and is more efficient than a connection-oriented 
service when higher layers perform whatever sequencing, flow 
control, and error recovery is required by user applications (in 
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fact, internetwork services are provided by the Network Layer). 
CDT also facilitates dynamic routing in packet- and 
message-switched networks, since each data unit (packet or 
message) can be directed along the most appropriate "next hop" 
unencumbered by connection-mandated node configurations. 
Examples of more or less connectionless network layer designs 
and implementations abound: Zilog’s Z-net (which offers both 
"reliable" and "unreliable" service options); DECNET’s 
"transport layer" (which corresponds to the OSI Network layer); 
Livermore Lab’s Delta-t protocol (although it provides only a 


reliable service, performing error checking, duplicate 
detection, and acknowledgement); the User Datagram protocol [48]; 
and the Cyclades network protocol[38]. In fact, even the 


staunchly connection-oriented X.25 public data networks 
(Canada’s Datapac is the best example) generally emply what 
amounts to a connectionless network-layer service in their 
internal packet switches, which enables them to perform flexible 
dynamic routing on a packet-by-packet basis. 


4.4 Transport Layer 


The connectionless transport service is important primarily in 
systems that distinguish the Transport layer and everything 
below it as providing something generically named the "Transport 
Service", and abandon or severely compromise adherence to the 
OSI architecture above the Transport layer. In such systems a 
connectionless transport service may be needed for the same 
reasons that other (more OSI-respecting) systems need a connec- 
tionless application service. Otherwise, the purpose of defin- 
ing a connectionless transport service is to enable a uniformly 
connectionless service to be passed efficiently through the 
Transport layer to higher layers. 


4.5 Session Layer 


The whole notion of a session which binds presentation-entities 
into a relationship of some temporal duration is inherently 
connection-oriented. The purpose of defining a connectionless 
session service, therefore, is to enable a uniformly connection- 
less service to be passed efficiently through the session layer 
to higher layers. In this sense, the connectionless session 
service stands in precisely the same relationship to the connec- 
tionless transport service as a session-connection stands to a 
transport-connection. 
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4.6 Presentation Layer 


Very much the same considerations apply to the Presentation 
layer as apply to the Session layer. 


4.7 Application Layer 


The most obvious reason to define a connectionless application 
service - to give user application processes access to the 
connectionless services of the architecture - is not the only 
one. The application layer performs functions that help user 
application processes to converse regarding the meaning of the 
information they exchange, and is also responsible for dealing 
with the overall system management aspects of the OSI operation. 
Over and above the many user-application requirements for 
connectionless service, it may be profitably employed by system 
management functions that monitor and report on the status of 
resources in the local open system; by application layer manage- 
ment functions that need to interact in a request-response mode 
with similar functions in other systems to perform security 
access control; and by user application process functions that 
monitor the status of activities in progress. 


The potential availability of two complementary services at each 
layer of the architecture raises an obvious question - how to 
choose between them? It should be clear at this point that 
unilateral exclusion of one or the other, although it may 
simplify the situation for some applications, is not a general 
solution to the problem. There are actually two parts to the 
question: how to select an appropriate set of cooperative 
services for all seven layers during the design of a particular 
open system; and, if one or more layers of the system will offer 
both connection-oriented and connectionless services, how to 
provide for the dynamic selection of one or the other in a given 
circumstance. 


The second part is easiest to dispose of, since actual systems - 
as opposed to the more abstract set of services and protocols 
collected under the banner of OSI - will generally be con- 
structed in such a way as to combine services cooperatively, 
with some attention paid to the way in which they will interact 
to meet specific goals. Although two services may be provided 
at a given layer, logical combinations of services for different 
applications will generally be assembled according to relatively 
simple rules established during the design of the system. 


Evaluating the requirements of the applications a system must 
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support and the characteristics of the preferred implementation 
technologies will also answer the first question. A system 
designed primarily to transport large files over a long-haul 
network would probably use only connection-oriented services. 
One designed to collect data from widely scattered sensors for 
processing at a central site might provide a connectionless 
application service but use a connection-oriented network 
service to achieve compatibility with a public data network. 
Another system, built around a local area network bus or ring, 
might use a connectionless data link service regardless of the 
applications supported; if several LANs sere to be 
interconnected, perhaps with other network types, it might also 
employ a connectionless internetwork service. 


The definition of OSI standard services and protocols, however, 
must consider the general case, so as to accomodate a wide range 
of actual-system configurations. The motivating principle 
should be to achieve a balance between the two goals of power 
and simplicity. The service definition for each layer must 
include both connection-oriented and connectionless services; 
otherwise, the utility of a service at one layer could be 
negated by the unavailability of a corresponding service else- 
where in the hierarchy. However, the role played by each 
service may be radically different from one layer to the next. 
The Presentation, Session, and Transport layers, for instance, 
need to support their respective connectionless services only 
because the Application layer, which must provide a connection- 
less service to user applications, cannot do so effectively if 
they do not. Recognizing these role variations opens up the 
possibility of restoring a measure of the simplicity lost in the 
introduction of choice at each layer by limiting, not the 
choices, but the places in the hierarchy where conversion from 
one choice to the other - connection to connectionless, or vice 
versa —- is allowed (see figure 6). At this stage in the devel- 
opment of the CDT concept, it appears that there are exscellent 
reasons for allowing such a conversion to take place in the 
Application, Transport, and Network layers (and in the Data Link 
layer, if some physical interconnection strategies are deemed to 
be connectionless). In the other layers, the provision of one 
kind of service to the next-higher layer must always be accom- 
plished by using the same kind of service from the next-lower 


layer (see figure 7). (This principle of like-to-like mapping 
is not related to multiplexing; it refers to service types 
(connection-oriented and connectionless), not to actual 


services.) Adopting such a restriction would contribute to the 
achievement of the balance mentioned above, without excluding 
those combinations of services that have demonstrated their 
usefulness. 
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5 Summary 


Support for incorporating connectionless data transmission as a 
basic architectural element of the Reference Model has grown as 
understanding of the concept has become more widespread. The 
protocol development sponsored by various agencies of the U.S. 
Department of Defense, for example, have long recognized connec- 
tions and connectionless transmission as complementary concepts, 
and have employed both. Similar work being carried out by a 
division of the Institute for Computer Science and Technology at 
the National Bureau of Standards, the result of which will be a 
series of Federal Information Processing Standards, depends 
heavily on connectionless as well as connection-oriented 
concepts. The importance of CDT to some of these U.S. efforts 
is reflected in comments received by ANSI committee X3T5 during 
the recent Reference Model ballot period, one of which states 
that "Publication of this material [DP7498] without incorpora- 


tion of the concerns associated with Connectionless Data 
Trans[mission] makes a mockery of U.S. interests."[18] A some- 
what less emotional expression of the same sentiment is embodied 
in the official U.S. Position on Connectionless Data 
Transmission[9], in which X3T5, the responsible DS: 
organization, "endorses SC16/N555 [Recommended Changes to 


Section 3 of [the Reference Model] to Include CDT] without 
exception and announces its intention to pursue vigorously the 
incorporation of CDT as the first major extension to the Basic 
Reference Model of OSI." In the same document, X3T5 notes that 
it "intends to issue and maintain a version of DP7498 to be 
referred to as DP7498-prime, incorporating the CDT extensions." 
That there is also significant international support for the CDT 
concept is clear, however, from the membership of the ISO 
SC16/WG1 Ad Hoc Group on Connectionless Data Transmission, which 
produced the N555 document last November; it includes represen- 
tatives from France, Japan, Germany, and the United Kingdom as 
well as from the U.S. Those who believe that the CDT concept is 
an essential part of the OSI architecture hope that eventually 
the DP7498-prime document, or its successor, will replace the 
exclusively connection-oriented Reference Model before the 
latter becomes an International Standard. 
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APPENDIX A — Vocabulary 


OSI Terminology 


The following terms are defined in either the text or the 
vocabulary annex (or both) of the Draft Proposed Reference Model 
of OSI (ISO/DP7498). Some terms are given more than one defini- 
tion in different sections of the Reference Model; these are 
marked with an asterisk (*), to indicate that selection of the 
accompanying definition involved the author’s personal 
judgement. 
[to be supplied] 


(N) -connection 
(N) -service-access-point 
(N) -service-access-point-address 
(N) -layer 
system 

(N) -entity 

(N) -connection-endpoint-identifier 


CDT Terminology 


The following terms, not yet part of the standard OSI 
vocabulary, relate to the concept of connectionless data 
transmission. 


"Connectionless Data Transmission is the transmission (not 
transfer) of an (N) -service-data-unit from a source 
(N) -service-access-point to one or more destination 
(N) -service-access-points without establishing an (N)-connection 
for the transmission." 


"A Connectionless (N)-Service is one that accomplishes’ the 
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transmission of a single self-contained (N)-service-data-unit 
between (N+1)-entities upon the performance of a single 
(N)-service access." 


Transmit: "to cause to pass or be conveyed through space or a 
medium." This term refers to the act of conveying only, without 
implying anything about reception. 


Transfer: "to convey from one place, person, or thing, to 
another." A one-way peer-to-peer connotation restricts the use 
of this term to cases in which the receiving peer is party to 
and accepts the data transferred. 


Exchange: "to give and receive, or lose and take, reciprocally, 
as things of the same kind." A two-way peer-to-peer connotation 
restricts the use of this term to cases in which both give and 
receive directions are clearly evident. 


datagram 

unit-data transfer/transmission 
transaction (from SC1/N688) 

data transmission (from DIS 2382 Section 9) 


[End of Appendix A] 
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